Unify whitespace across translations (zh-cn.ts) - #2

顺便一提 zh-tw.ts 的翻译是拿 zh-cn.ts 生成的。所以如果你确实想同时维护简中和繁中的话，没必要像我改这些多语言一样再手动弄了，就像一开始发布这个人一样，简中改完了直接重新生成，会更划算一些。我是觉得搞繁中的人，应该是会等简中更着更着又多了之后，隔段时间又重新生成一个提交的。

@playermiller109 zsviczian 在 en.ts 中的格式挺乱的，上一次甚至少了一个换行，然后我做了修改，他却没有把提交合并进去。我猜测他可能是在完成自己代码之后才处理一下 pr，然后将不存在冲突的合并进去。所以现在我尽量不动 en.ts。

我觉得格式带来的影响并不是很大，更希望让 zsviczian 将精力放在主要功能上，而不去纠结这些细节。

统一的格式也使得检测缺失的翻译变得更加容易——例如，通过比较行数或通过视觉检查发现空缺。

目前行号是严谨对应的，如果未能正确对应，我便会进行检查，所以有一些空行或者换行是故意的，就是为了保持两个文件的高度一致。

zh-cn.ts 中注释行（// ...）内的不必要的空白和翻译编辑

这部分我回头做一下整理，以后也尽量注意。因为是使用 AI 翻译然后人工检查修正的方式，所以有一些中文注释是在翻译过程中产生的。

所以如果你确实想同时维护简中和繁中的话

繁中没有标明上次跟进到了哪个提交，所以昨晚我做了一次整体的对照。目前是和简中同步进行手动操作，后续看情况吧。

我觉得目前使用繁体中文的人多数对简体中文没有阅读障碍，所以就一直没有搞繁体，但既然有人提交了，以后我也尽量跟进更新一下吧。

转换的问题回头我再看看，一方面是复杂度提升我可能操作出问题的概率就更大，另一方面我总觉得机器翻译或者转换在一些细节上还是可能存在问题，尽量全部做一遍人工检查。所以在数量不大的情况下手动处理和进行转换的工作量区别不大。

关于提交冲突

@dmscode 你提到的“上次没合并的提交”，那个换行的修改，作者在你 PR zsviczian#2407 的时候还是给合并了。

因为 2407 这个 PR 内容是在你 zsviczian#2399 PR 基础上更新的版本，合并了新的旧的肯定就不会再合并了。之前没有立刻合并可能只没看到，并不是说改了就不给合并。

如果你的意思是说你感觉之前没合并是因为作者每次发新版本的时候才来统一合并，之前忘记合并你的修改，下次来的时候，他的 en.ts 有了新修改，然后就不给合并了。

首先，有冲突时，有很多解决办法。PR 者可以变基后 push -f，作者在合并的时候程序也会自动调用差异编辑器进行冲突合并。

这也是为啥我会说“如果有疑虑请随时联系”——我也没觉得作者肯定会合并，如果他或者任何人觉得有地方需要解释，或者要求我再进行一些修改，他们可以在 PR 下直接告诉我；或者作者不搭理这个 PR，隔会儿我看时间差不多了，觉得不太可能合并了，我也就自己关了。

关于修改内容

我主要是不太理解为什么你只修改 zh-cn.ts 冒号前面的空格。

如果无关空白字符，那就像以前一样只添加新内容就好，不用做任何空白字符的处理。

如果觉得我这个修改只有一部分合适，一般会在 PR 下说能不能解释一下这里这里或者能不能改成什么什么之类的吧。或者说我要继续更新内容了，我怕和你这个产生冲突，你能不能怎么怎么的。

核心在于这个修改意图不明确：为什么其他部分不改呢？就算不动 en.ts，也不管注释什么的，只修改 zh-cn.ts 冒号前面的空格也不能让 zh-cn.ts 和 en.ts 统一啊。

那个“故意的空行”我也看到了，是 en.ts 多换了几行。如果你不动 en.ts 的话，那确实 zh-cn.ts 也就只能跟着多换几行了。

关于繁体中文

繁中那个后续你想人工跟进也没啥，但是至少像改空白字符这种初始提交还是可以重新生成新文件，再拿差异编辑器撤回人工修改的部分就完成了，不用改两遍嘛。

主要港澳台也各有各的用语区别，你给人家改了，人家不见得满意。不过估计也不会有人有特别大的意见就是了。

我觉得这件事情应该让作者自己决定是否重要，提交 PR 也不是让作者自己进行这些格式调整，是我们改好了，作者只需要应用就可以了。我认为这符合你所说的，让作者将精力放在主要功能上，而不去纠结这些细节，因为细节由我们帮忙完善。

但我也尊重你的意见。因此我希望知道你是否还需要我的这些修改中的部分修改，我可以调整 PR 内容，这样你就不用在你的本地再改一次。或者我就直接关闭 PR 了。

首先，上面我只是想表达自己对这个问题的看法，我同样认为 “这件事情应该让作者自己决定是否重要”。毕竟为了便于操作，其他的语言文件都要以 en.ts 文件作为蓝本。

我主要是不太理解为什么你只修改 zh-cn.ts 冒号前面的空格。

这个问题解释起来会很搞笑——因为我的操作水平非常有限，同时精力也很有限，所以更倾向于一种方法不出问题就坚持使用同样的方法而不做改变，因为有时候 git 出了问题我不知道应该如何处理，只能放弃一切完全重新开始。

所以从我个人的角度，我完全接受你提出的问题，但我自己得逐个问题去解决——当然我知道你已经将这些问题解决了，我只需要合并就好——但同时存在延伸的问题，就是每一个被解决的问题我都要记住以后去注意这样的细节。所以在我的内心有点想这样一点一点的去推进……

但是，真正的误会是 ——在修改的时候因为我要对比多个文件之间有差异，然后发现了冒号之间空格产生的影响，所以就将它进行了整理。做完这一切之后才看到你提交的 pr。而并不是“只修改”。

港澳台也各有各的用语区别

正是因为知道这些，所以前面一直都不太想去动繁体中文。但现在既然有了，那么跟进一下也没所谓，在一些词汇上尽量去保持一致就行了。

比如昨天“插件”被翻译成了“外挂程式”，但检查一下其他翻译都写的是“外挂”，所以我也调整为了“外挂”

最后，如果你不介意我的缓慢，我想按照你列出的问题去逐个整理解决一遍，同时可能理顺一下我的工作流。毕竟以前只是心血来潮，但长期坚持的话确实应该去完善许多细节。

@dmscode 了解，那就关闭了。

@playermiller109 我把你提到的问题尽量检查整理了一遍，也发现了一些其他细节上的问题。并且书写了一个简易的 diff 脚本，用来对照 key 的差异。

但…因此，我发现了令我十分抓狂的问题∑(ﾟДﾟﾉ)ﾉ——我接手的时候只对新增的条目进行了翻译，之后就是跟进每一次变化。然而，原有的条目内容可能早就发生了变化……Σ(っ°Д°;)っ这意味着后面我需要花时间对所有的内容进行对照检查，一项十分巨大的工作……

@dmscode 其实我在今年五月份做了一个本地项目 在本地维护 Excalidraw 插件的中文翻译，但是改动风格差异蛮大的，而且我最近在重新调整这个项目。这个说明给的仓库链接以及术语说明，你现在还是能查看，但是那个子仓库我已经删掉了。你可以先看看思路。

内容太多，时间跨度太大，无论是原作者还是翻译者，都很难进行维护。

我考虑先把严重内容差异的部分给整理一下，也许在整理过程中可以建立一个翻译词典，用来统一一些短语的翻译。但是英文中有一些相同含义的内容，使用的也是不同的表达方式。

一点一点儿来吧，整体检查一遍的工作量跟整个重新翻译一遍也差不太多了。